前言

在上一篇文章中介紹了目前 CDN 搬遷的過程，以及在過程中遇到的問題與挑戰。這篇文章會針對技術上學習到的東西來再與各位進行下一步的分享。

主文

Multi-Domain & SAN Certificate

Multi-Domain 是筆者花最多時間研究的東西了。在上一篇文章中也有稍微提到過，這是為了節省預算而做的設，而在舊廠商中，我們透過 Subject Alternative Name (SAN) Certificate 來達到這件事情。

以 www.google.com 為例，在 SSL Lab 的 SSL Server Test 中，可以看到類似以下的結果截圖：

使用了 SAN Certificate 的我們，在圖中被紅線框起來的 Alternative names 中，就會看到一連串不同的 domain，這些 domain 都共同同一組憑證。

在嘗試使用 multi-domain 時，大致上有兩種不同的手段。如果 root domain 相同，那其實可以直接很簡單地設定 wildcard 即可。比如 *.service.com 就可以被套用在 www.service.com 和 api.service.com 等等。如果 root domain 不同，那就可以使用 SAN Certificate 來解決這個問題。相關的介紹可以再參考用 SAN Certificate 做 Multi-Domain Certificate | by Allan Sun | 隨筆雜記 (cssuen.tw)。

Certificate Validation Level

在憑證的 validation 等級中，主要總共分為三種，分別是 Domain Validation (DV)、Organization Validation (OV)、Extended Validation (EV)。這三者的安全性以 EV 最高，OV 次之，DV 最低，可想而之的是，驗證的麻煩程度以及價格則與安全性的排序反過來。

DV 應該是最普遍也最常見的 validation 等級了。在一般我們使用 TLS 憑證的時候，一開始都會使用到這個等級的憑證，驗證方式也相對單純，只需要證明你是該網域的擁有者即可。OV 的部分則如其名，會需要提供組職相關的證明文件，因此也相對秏時。EV 則是最高等級，也是最貴的等級，目前筆者自己也還沒有看過。

可以參考Learn About SSL Certificates' Authentication Levels (thesslstore.com)的說明。

跟據前人的說法，在舊廠商的設定中，似乎是因為 SAN Certificate 的關係而需要使用到 OV 的等級，但該𥀱商在 OV 等級的憑證上無法自動更新，因此每隔一段時間就會需要手動更新憑證。因此，在與新廠商的斡旋中，新廠商提供了他們所獨立擁有的特別技術，在能夠達到 multi-domain 的前提下，僅使用 DV 而且可以自動更新憑證，算是有效解決了我們其中一個原本的痛點。

Zero-Rating

Zero-rating 的意思，是在符合某種特定的條件下，業者提供使用者網路使用但不額外計費的一種商業模式。比如說，業者可能承諾使用者在存取特定軟體或網站，或以特定 IP 使用服務的時候不計費。可能因為有時候網路使用量非常高，如果按照使用量來計費會造成使用者的怯步，因此才出現了這種類似「吃到飽」的概念。如果讀者以這個關鍵字查詢，可能會找到一些法律上的，以及在不同國家中可能有不同規則上的爭論，有興趣的話也可以再自行往下研讀。

可以參考維基百科的說明：Zero-rating - Wikipedia。

Anycast

會提到 Zero-Rating，主要是我們想透過特定 IP 不計費的方式來提供服務。而在此就牽涉到了 Anycast 這項技術。在網路路由的世界中，有四個比較主要的規則，分別是 Unicast、Broadcast、Multicast、Anycast。請參考來源為維基百科(Anycast - Wikipedia)的下圖：

Unicast 是一個一對一的路由關係；Broadcast 會路由到所有包含在 broadcast address 中的 endpoint；Multicast 是一對多的路由關係；Anycast 雖然也是一對多，但一次只會路由到其中一個(通常是最近)的 endpoint。

因為 Anycast 的技術可以用來將同一個 IP 位址對應到數個 edge server，在實際請求進來的時候又可以將流量導向最近的對象，因此這就很適合用在我們所需要的 CDN 服務中。而新廠商所使用到的，正是 Anycast 的技術沒有錯。

關於 Anycast 與 CDN 的應用關係，也可以再參考另一篇筆者認為寫得非常好的文章。

後記

說實話，CDN 對於筆者而言可以算是一個全新的領域。過去筆者對 CDN 的認知，就只是一個類似快取的概念，並稍微理解 Edge 和 Origin 之間的差異而已。但在這次 CDN 的搬遷評估中，除了前一篇文章中有遇到的，一些非技術挑戰和單純新廠商設定上的問題外，更重要還是在整個研究的過程裡面，開始又對 CDN 這個領域有了進一步的認識。

此外，因為要處理的範圍非常大，而每個範圍又常出現許多無法馬上解決的細節問題。這導致初期許多精神錯亂的狀況，比如筆者會在隔了一個週末後，忘記上週在 CDN 這裡的進度，或是常常開完會之後才想到忘記討論某個細節。換個說法，這裡也許還牽涉到一整個專案管理的技巧，不單純只是技術上的問題而已。要如何有效地整理已完成事項和待辦清單，並在合理的時間內將各任務逐一解決，也許反而是這個工作中最大的挑戰吧。

最後，不得不說，雖然一直都有認知到 SRE 的守備範圍非常廣，但常常也是在實際有相關需求的時候，才發現相關技術遠比自己想像中的還要深上許多。即使費盡心力整理出目前的心得，也還是沒有完全確定自己的理解是否正確，如果讀者有任何不同的意見，都歡迎提出來討論。

鐵人賽系列文章進入尾聲，但接下來的文章也會一樣精彩。